Event based gps tracking

ABSTRACT

System and method for enabling predefined events to be used to trigger the collection of vehicle position data. A combination GSM device and GPS device is used to collect vehicle position data and to convey that position data to a remote computing device for review and/or analysis. There is a tradeoff between collecting too much data (cell phone bill is too high) and collecting too little data (value added analytics cannot be achieved without sufficient data). The concepts disclosed herein relate to method and apparatus to enable the data collection/transmission paradigm of such a GSM/GPS to be varied (or triggered) based on the detection of one or more predefined events. This enables data which can contribute to value added analytics to be acquired, without wasting airtime on unimportant data.

RELATED APPLICATIONS

This application is based on a prior copending provisional applicationSer. No. 61/610,975, filed on Mar. 14, 2012, the benefit of the filingdate of which is hereby claimed under 35 U.S.C. §119(e).

BACKGROUND

As the cost of sensors, communications systems and navigational systemshas dropped, operators of commercial and fleet vehicles now have theability to collect a tremendous amount of data about the vehicles thatthey operate, including geographical position data (generally referredto herein as GPS data, noting that position data can be collected bysystems related to but distinct from the well-known Global PositioningSystem) collected during the operation of the vehicle.

Vehicle fleet operators often operate vehicles along predefined andgenerally invariant routes. For example, buses frequently operate onpredefined routes, according to a predefined time schedule (for example,along a route that is geographically, as well as temporally defined). Itwould be desirable to provide new techniques for analyzing datacollected from vehicles transiting such predefined routes over time, toaid in identifying vehicle performance problems requiring servicing.

Vehicle fleet operators often operate vehicles both on road and offroad. Significantly, fuel tax is calculated differently for on-road andoff-road use. It would be desirable to provide new techniques foranalyzing data collected from vehicles operating both on road and offroad, to enable fuel tax calculations to be performed more accurately.

Transmitting data from a vehicle to a remote server can be accomplishedusing GSM technology. There is a tradeoff between collecting too muchdata (cell phone bills are too high) and collecting too little data(value-added analytics cannot be achieved without sufficient data). Itwould be desirable to provide method and apparatus to collect usefulamounts of data without wasting bandwidth on less valuable data.

SUMMARY

One aspect of the novel concepts presented herein is a system and methodfor enabling predefined events to be used to trigger the collection ofsuch event data and vehicle position data. A combination GSM device andGPS device is used to collect vehicle position data and to convey thatposition data to a remote computing device for review and/or analysis.There is a tradeoff between collecting too much data (cell phone billsare too high) and collecting too little data (value-added analyticscannot be achieved without sufficient data). The concepts disclosedherein relate to method and apparatus to enable the datacollection/transmission paradigm of such a GSM/GPS device to be varied(or triggered) based on the detection of one or more predefined events.This enables data which can contribute to value added analytics to beacquired, without wasting airtime on less important data.

One paradigm for collecting and transmitting GPS data using a GSM/GPSdevice (or a separate GSM device coupled to a GPS, noting that theconcepts disclosed herein can also be implemented using other forms ofwireless data transfer, including but not limited to satellite) is tocollect GPS data at predetermined intervals, or according to somealgorithm that changes the vehicle position data collecting paradigmbased on changes in vehicle speed or heading (such an algorithm canenable relatively more data to be collected during city driving versustraveling along a straight section of highway with little change inspeed or heading). The concepts disclosed herein are based on modifyingthe frequency with which GPS data is collected and transmitted to aremote server, based on non-position related inputs received from thevehicle (i.e., not simply a change in speed or heading as in the abovedescribed algorithm). In an exemplary embodiment, those non-positionrelated inputs are acquired from a vehicle data bus, such as a J1939,J1708, and/or CAN bus. In certain embodiments, those on non-positionrelated inputs can be received from an OBD or OBD-II interface.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when an amount of fuel passing through fuel injectorsincreases, such that a GPS data point is acquired when fuel useincreases. In an exemplary embodiment, the data point includes fuel usedata and GPS data. Such data will enable vehicle operators to understandat what vehicle locations their fuel usage increases.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when an amount of fuel passing through fuel injectorsdecreases, such that a GPS data point is acquired when fuel usedecreases. In an exemplary embodiment, the data point includes fuel usedata and GPS data. Such data will enable vehicle operators to understandat what vehicle locations their fuel usage decrease.

While relating fuel use to fuel passing through injectors represents anexemplary technique for determining changes in fuel use that triggercollection of a GPS data point and fuel use data, it should beunderstood that other types of sensors related to fuel use can besimilarly employed (such as a flow sensor in a fuel line). Any inputproviding insight into changes (decreases or increases) in fuelconsumption can be used as an input.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when a throttle position changes, such that a GPS data point isacquired when throttle position changes. In an exemplary embodiment, thedata point includes throttle position and GPS data. Such data willenable vehicle operators to understand at what vehicle locations theirthrottle positions change.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when engine, oil, coolant and/or brake temperatures change,such that a GPS data point is acquired when such temperature changesoccur. In an exemplary embodiment, the data point includes temperaturedata and GPS data. Such data will enable vehicle operators to understandat what vehicle locations their vehicle system's temperatures change.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when accessory devices such as fans are energized, such that aGPS data point is acquired when such accessory devices are used. In anexemplary embodiment, the data point includes the identity of theaccessory device, any measured parasitic load, and GPS data. Such datawill enable vehicle operators to understand at what vehicle locationsthe vehicle's parasitic loads increase, which generally relates to adecrease in fuel economy.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when cruise control is turned on or off, such that a GPS datapoint is acquired when cruise control is turned on or off. In anexemplary embodiment, the data point includes the status of the cruisecontrol unit and GPS data. Such data will enable vehicle operators tounderstand at what vehicle locations cruise control is and is notemployed.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when a driver changes gears, such that a GPS data point isacquired when such shifting occurs. In an exemplary embodiment, the datapoint includes the selected gear (RPM can also be collected if desired)and GPS data. Such data will enable vehicle operators to understand atwhat vehicle locations the driver shifts gears. Shifting patterns canhave a measurable impact on fuel economy.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when engine load changes, such that a GPS data point isacquired when such engine load changes. Engine load is not simply RPM,and many vehicle ECU units are configured to calculate engine load. Inan exemplary embodiment, the data point includes the engine load and GPSdata. Such data will enable vehicle operators to understand at whatvehicle locations the engine loads increase or decrease.

In at least one embodiment, inclinometers, accelerometers, or hardbraking sensors are used to similarly change an existing GPS dataacquisition paradigm.

In at least one embodiment, an existing GPS data acquisition paradigm ismodified when engine RPM changes, such that a GPS data point is acquiredwhen engine RPM increases or decreases. In an exemplary embodiment, thedata point includes RPM data and GPS data. Such data will enable vehicleoperators to understand at what vehicle locations their RPMs change. Itshould be understood that limits can be placed on how much the engineRPMs need to vary to trigger a change. For example, some operators maywish to track RMP changes of about 10% or more, while other operatorsmay wish to track RPM changes of about 50 or more RPMs. It should berecognized that such RPM changes are intended to be exemplary, and notlimiting. Further, with respect to that other non-position based eventchanges disclosed herein (i.e., fuel use, temperature, throttleposition, etc.), it should be recognized that changing an existing GPSdata acquisition paradigm can be based on any change in the specificparameter, or a certain magnitude of a change in that parameter.Further, the concepts disclosed herein encompass embodiments where themagnitude of the change needed to trigger modification of an existingGPS data acquisition paradigm can itself be modified (i.e., themagnitude can be modified). The concepts disclosed herein encompassembodiments where the magnitude of the change triggering themodification of the existing GPS data acquisition paradigm can bemodified by users; such that users can reprogram the logic controllingthe GPS data acquisition paradigm to modify the magnitude parameters ofnon-position based events that trigger a change in the existing GPS dataacquisition paradigm.

In addition to being implemented as a method, the concepts disclosedherein can also be implemented as a memory medium, storing machineinstructions that when executed by a processor implement the method, andby a system for implementing the method. In such a system, the basicelements include a vehicle that is to be operated by a vehicle operator,data collection components in the vehicle (sensors/controllers fordetermining parameters such as fuel use, temperature, RMP, load,shifting patterns, throttle position, use of accessory components, useof cruise control, etc.), and a geographical position tracking unit(such as a GPS tracking device), a processor for combining the differentdata types into time indexed parameter (fuel use, temperature, RMP,load, shifting patterns, throttle position, use of accessory components,use of cruise control, etc.) encoded position data (such a processorcould be part of the GPS unit), a data link (which in an exemplaryembodiment is integrated into the GPS unit as a wireless data link), anda remote computing device. In general, the remote computing device canbe implemented by a computing system employed by an entity operating afleet of vehicles. Entities that operate vehicle fleets can thus usesuch computing systems to track and process data relating to theirvehicle fleet. It should be recognized that these basic elements can becombined in many different configurations to achieve the exemplarymethod discussed above. Thus, the details provided herein are intendedto be exemplary and not limiting on the scope of the concepts disclosedherein.

The above noted method is preferably implemented by a processor (such ascomputing device implementing machine instructions to implement thespecific functions noted above) or a custom circuit (such as anapplication specific integrated circuit).

Other concepts that can be combined with the modification of a GPS datacollection paradigm include the following. A method of combining fueluse data collected by a vehicle's fuel injector with position datacollected during operation of the vehicle, to generate fuel use encodedposition data. Such fuel use encoded position data preferably is fourdimensional: position (latitude & longitude), time, fuel injector data,and odometer data. Generating such data requires the vehicle to beequipped with a position sensing system (able to determine the vehicle'slatitude & longitude per unit of time), and a sensor incorporated intoat least one fuel injection component, to enable an amount of fuelintroduced into the vehicle's engine to be determined per unit of time.Diesel engines that include fuel injectors configured to collectinformation about the flow of fuel through the injectors per unit timeare currently available. In an exemplary, but not limiting embodiment,the odometer data is collected from the vehicle computer using a J-1708or J-1939 bus. While including the odometer data is likely to be popularwith end users, it should be understood that the concepts disclosedherein also encompass embodiments in which the odometer data is notincluded in the fuel use encoded position data.

Such fuel use encoded position data has a number of uses. The data canbe used to determine fuel usage of the vehicle under many differentsearch parameters. For example, many commercial trucks are used both onand off road. Diesel fuel for highway use is taxed at a much higher ratethan diesel fuel for non-highway use (diesel for off road use isgenerally exempt from Federal and State road taxes). The fuel useencoded position data can be used to calculate how much diesel fuel isconsumed when the vehicle is not on the highway (i.e., when the lowertax rate applies). Normally this metric is calculated using an averageMPG. If the off-road trip was 20 miles round trip and the vehicle MPGaverages 10 MPG, then 2 gallons of diesel were assumed to be used. Thatcalculation is very error prone. Off road fuel consumption is oftenhigher for a number of reasons. Road condition is poorer, so fuelconsumption generally is higher. Many commercial vehicles going off roadare maintenance vehicles equipped with power take off units, which useengine power to do mechanical work other than driving road wheels. Thus,even when the vehicle is not moving, the engine is often consuming fuelto power ancillary equipment. A mileage based calculation will not takeinto account the fuel consumed off road when the vehicle is stationary,but consuming fuel to power equipment.

The fuel use encoded position data can also be used to evaluate themechanical condition of a vehicle. Assume a vehicle travels from point Ato point B consistently. By monitoring fuel use for that trip over aperiod of time, a decrease in fuel efficiency may indicate a mechanicalproblem (dirty injectors, fouled spark plugs, etc.).

Yet another use for the fuel use encoded position data is to provide adata set to be used to analyze fuel consumption relative to elevationchange. By quantifying how much fuel is consumed traveling over a routewith elevation changes, one can identify alternate, possibly longerroutes, that are more fuel efficient, due to fewer elevation changes. Arelated use for the fuel use encoded position data is to provide a dataset to be used to analyze fuel consumption relative to road surface.Analyzing fuel consumption relative to the type of road surface willenable vehicle operators to learn what road type surfaces are associatedwith lower fuel consumption. Regularly traveled routes can then beanalyzed to determine if an alternate route over different road surfacescould lead to lower fuel consumption. Correlating the fuel use encodedposition data with vehicle loading data can also facilitate analysis offuel consumption not only based on elevation and road surface, butvehicle loading as well.

It should be recognized that one aspect of the concepts disclosed hereinis a method for generating fuel use encoded position data by combiningfuel usage data (per unit of time) collected by fuel injectors withposition data (per unit of time). Another aspect of the conceptsdisclosed herein is a method for collecting fuel use encoded positiondata at a remote computer, by wirelessly transmitting the fuel useencoded position data from the vehicle to a remote computer inreal-time. The term real-time is not intended to imply the data istransmitted instantaneously, rather the data is collected over arelatively short period of time (over a period of seconds or minutes),and transmitted to the remote computing device on an ongoing basis, asopposed to storing the data at the vehicle for an extended period oftime (hour or days), and transmitting an extended data set to the remotecomputing device after the data set has been collected. Transmittingfuel use encoded position data at a later time, rather than in realtime, is encompassed by the concepts disclosed herein, althoughreal-time data transmission is likely to be popular with users.

Another aspect of the concepts disclosed herein is a method for usingfuel use encoded position data to calculate fuel use taxes. While thefuel tax calculations could be performed by a processor in the vehicle,in a preferred but not limiting embodiment, the fuel use encodedposition data will be transferred to the remote computing device forstorage, such that the fuel use encoded position data for a particularvehicle can be accessed at a later time to perform the fuel taxcalculations. It should be understood that the term remote computer andthe term remote computing device are intended to encompass networkedcomputers, including servers and clients, in private networks or as partof the Internet. The fuel use encoded position data can be stored by oneelement in such a network, retrieved for review by another element inthe network, and analyzed by yet another element in the network. In atleast one embodiment, a vendor is responsible for storing the data, andclients of the vendor are able to access and manipulate the fuel useencoded position data.

Still another aspect of the concepts disclosed herein is a method forusing fuel use encoded position data to diagnose a relative mechanicalcondition of a vehicle that repetitively travels a specific route. Fueluse encoded position data for different trips can be compared. Changesin fuel use encoded position data can indicate that a fuel efficiency ofthe vehicle has decreased over time, indicating that the vehicle shouldbe inspected for mechanical conditions (such as dirty fuel filter, dirtyair filters, and/or clogged fuel injectors, noting that such examplesare not intended to be limiting) that may be contributing to a reductionin fuel efficiency.

Still another aspect of the concepts disclosed herein is a method forenabling a user to define specific parameters to be used to analyze suchfuel use encoded position data. In an exemplary embodiment, a user candefine a geographical parameter, and analyze the fuel use encodedposition data in terms of the user defined geographical parameter. In anexemplary embodiment, the geographical parameter is a geofence, whichcan be generated by displaying a map to a user, and enabling the user todefine a perimeter “fence” around any portion of the map. Having definedthe geofence, the user can then analyze the fuel use encoded positiondata for the vehicle, such that only the portion of the fuel use encodedposition data whose geographical/position data falls within the confinesof the geofence is included in the analysis. One such analysis can befuel tax calculations, where the geofence is used to define off roadvehicular use. Another such analysis can be determine how fuel usepatterns change over time, where the geofence is used to define aspecific route (such as a bus route or an invariant delivery route). Inanother exemplary embodiment, the geographical parameter is a set ofgeographical coordinates. As discussed above, some vehicles regularlytravel a predefined route, and the predefined route can be defined by aset of geographical coordinates that the vehicle encounters whenevertransiting that route. A larger data set will include more geographicalcoordinates. A relatively larger set of geographical coordinates will begenerated if the set of geographical coordinates includes individualgeographical coordinates separated from one another by 25 feet. Arelatively smaller set of geographical coordinates will be generated ifthe set of geographical coordinates includes individual geographicalcoordinates from each intersection at which the vehicle makes a turn orchange in direction (such that geographical coordinates defining wherethe vehicle enters and exits a relatively long street can be separatedfrom one another by relatively long distances). Such a set ofgeographical coordinates can be considered to define a fingerprint for aspecific route. An exemplary analysis of fuel use encoded position datawhere the geographical parameter is a route fingerprint is to determinehow fuel use patterns change over time as the route is completed atdifferent times. Changes in fuel use patterns can indicate that a fuelefficiency of the vehicle has decreased over time, indicating that thevehicle should be inspected for mechanical conditions, generally asdiscussed above.

In addition to being implemented as a method, the concepts disclosedherein can also be implemented as a memory medium, storing machineinstructions that when executed by a processor implement the method, andby a system for implementing the method. In such a system, the basicelements include a vehicle that is to be operated by a vehicle operator,data collection components in the vehicle (injectors that collect fueluse data per unit time, and a geographical position tracking unit, suchas a GPS tracking device), a processor for combining the different datatypes into time indexed fuel use encoded position data (such a processorcould be part of the GPS unit), a data link (which in an exemplaryembodiment is integrated into the GPS unit as a wireless data link), anda remote computing device. In general, the remote computing device canbe implemented by a computing system employed by an entity operating afleet of vehicles. Entities that operate vehicle fleets can thus usesuch computing systems to track and process data relating to theirvehicle fleet. It should be recognized that these basic elements can becombined in many different configurations to achieve the exemplarymethod discussed above. Thus, the details provided herein are intendedto be exemplary and not limiting on the scope of the concepts disclosedherein.

The above noted method is preferably implemented by a processor (such ascomputing device implementing machine instructions to implement thespecific functions noted above) or a custom circuit (such as anapplication specific integrated circuit).

This Summary has been provided to introduce a few concepts in asimplified form that are further described in detail below in theDescription. However, this Summary is not intended to identify key oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

DRAWINGS

Various aspects and attendant advantages of one or more exemplaryembodiments and modifications thereto will become more readilyappreciated as the same becomes better understood by reference to thefollowing detailed description, when taken in conjunction with theaccompanying drawings, wherein:

FIG. 1 is a high level logic diagram showing exemplary overall methodsteps implemented in accord with the concepts disclosed herein tocombine fuel use data collected from a fuel injector with geographicalposition data collected while a vehicle is in operation, to generatefuel use encoded position data, which can be subsequently analyzed todetermine at least one operational parameter of the vehicle;

FIG. 2 is a functional block diagram of an exemplary computing devicethat can be employed to implement some of the method steps disclosedherein;

FIG. 3 is a functional block diagram of an exemplary geographicalposition sensing system employed to implement some of the conceptsdisclosed herein;

FIG. 4 is an exemplary functional block diagram showing the basicfunctional components used to implement the method steps of FIG. 1;

FIG. 5 is a schematic block diagram of an exemplary vehicle configuredto collect the fuel use encoded position data employed in the methodsteps of FIG. 1;

FIG. 6 is a high level logic diagram showing exemplary overall methodsteps implemented in accord with the concepts disclosed herein, andsummarized above, to utilize fuel encoded position data collected todetermine at least one operational characteristic of the vehicle, wherethe analysis includes enabling the user to define a geofence;

FIG. 7 is a flow chart showing exemplary method steps implemented toutilize fuel encoded position data collected by a vehicle to analyzefuel use patterns based on elevation changes;

FIG. 8 is a flow chart showing exemplary method steps implemented toutilize fuel encoded position data collected by a vehicle to analyzefuel use patterns based on different types of road surfaces;

FIG. 9 is a flow chart showing exemplary method steps implemented tomodify a GPS logging paradigm based on the detection of one or morenon-position related parameters;

FIG. 10A schematically illustrates a GPS logging paradigm based on GPSlogging at predetermined time intervals;

FIG. 10B schematically illustrates a GPS logging paradigm based on GPSlogging at predetermined time intervals modified based on position basedparameters;

FIG. 10C schematically illustrates the GPS logging paradigm of FIG. 10Bmodified based on detecting a non-position based parameter;

FIG. 11 is a screen shot of a web page upon which a vehicle owner canview fuel use data overlaid upon vehicle route data, where the fuel usedata was collected using the method of FIG. 9; and

FIG. 12 is a functional block diagram of an exemplary telematics deviceadded to an enrolled vehicle to implement one or more of the methods ofFIGS. 1 and 9.

DESCRIPTION Figures and Disclosed Embodiments are not Limiting

Exemplary embodiments are illustrated in referenced Figures of thedrawings. It is intended that the embodiments and Figures disclosedherein are to be considered illustrative rather than restrictive.Further, it should be understood that any feature of one embodimentdisclosed herein can be combined with one or more features of any otherembodiment that is disclosed, unless otherwise indicated.

Newly Disclosed Subject Matter

The concepts disclosed herein relate to both newly disclosed subjectmatter and previously disclosed subject matter. The previously disclosedsubject matter provides contextual information that is relevant to thenew disclosure, hence it inclusion. The newly disclosed subject matterbegins with FIG. 9.

Related Subject Matter Disclosed in U.S. patent application Ser. No.12/836,487

As used herein and in the claims that follow, the term off road isintended to refer to use of a vehicle where fuel consumed by thatvehicle should be assessed a tax using a tax rate different than fuelconsumed by the same vehicle when traveling over a public highway. Theconcepts disclosed herein can help vehicle operators more

As used herein and in the claims that follow, the term route is intendedto refer to a route between a starting location and an ending locationthat is intended to be traversed a plurality of times. For example, busoperators generally operate buses on a number of different specificroutes, which are generally differentiated by a route number. A busRoute 51 might connect a shopping mall and an airport, while a bus Route52 might connect the airport to a university. Route 51 and Route 52 areeach different routes. A route may include one or more intermediatelocations disposed between the starting location and the endinglocation, such intermediate locations representing geographicallocations that the route intersects. Each route can be defined by aplurality of geographical coordinates through which a vehicle will passwhen traversing the route. As such, a set of position data collectedduring the operation of a vehicle can be used to define a route.

FIG. 1 is a high level flow chart showing the overall method stepsimplemented in accord with one aspect of the concepts disclosed herein,to collect fuel use data from a fuel injector sensor and position data,then combine the data to generate fuel use encoded position data, whichcan be analyzed to determine at least one operating characteristic ofthe vehicle. In a block 10, a vehicle is equipped with geographicalposition sensors (such as a GPS unit), so that geographical positiondata can be collected when the vehicle is being operated, and a fuelinjector that measures a quantity of fuel flowing through the fuelinjector. Mercedes Benz manufactures diesel engines that incorporatefuel injectors capable of providing such fuel use data. Other vendorswill likely offer engines having similar functionality. In general, eachfuel injector in the vehicle will include such a fuel sensor. However,it should be recognized that less than all of the fuel injectors caninclude such sensors, so long as the data for the engine's fuel use isadjusted to compensate (i.e., an engine with four injectors, only one ofwhich includes a fuel sensor, should have its measured fuel useincreased fourfold to account for fuel flow through the unmonitoredinjectors). In an exemplary but not limiting embodiment, fuel injectordata is collected from the vehicle computer using either a J-1708 orJ-1939 bus. The data values are generally in English unit using theJ-1708 bus and metric units using the J-1939 bus. The J-1939 busprovides fuel injector data with ½ liter resolution. In general, thevehicle computer will receive from usage data from each cylinder's fuelinjector. It would be possible to collect fuel use data from only asingle injector in a multi-cylinder engine, and then increase that databy a factor corresponding to the number of cylinders. Similarly, datacould be collected from ½ of the injectors, and then doubled tonormalize the data for fuel use in all cylinders.

In a block 12, the vehicle is operated while collecting both GPS data(i.e., position data, preferably including time indexed longitude andlatitude data) and fuel use data (as measured through the fuelinjectors). The different types of data are combined into a time indexeddata set. In an exemplary embodiment, the different types of data(position and fuel use) are combined by a geographical position sensingsystem, an exemplary implementation of which is discussed in detailbelow to generate fuel use encoded position data.

In a block 14, the fuel use encoded position data collected duringoperation of the vehicle is conveyed to a remote computing device. Inone exemplary, but not limiting embodiment, the fuel use encodedposition data is wirelessly transmitted to the remote computing deviceon the fly (i.e., as the information is generated). In such anembodiment, it may be desirable to store a copy of the fuel use encodedposition data at the vehicle in case of a failure in the transmission ofthe data stream. In another exemplary embodiment, the fuel use encodedposition data is stored in the vehicle, and conveyed to the remotecomputing device at a later time.

In a block 16, the fuel use encoded position data conveyed to the remotecomputing device is analyzed to determine at least one operationalcharacteristic of the vehicle. The fuel use encoded position data can beused to determine fuel usage of the vehicle under many different searchparameters. In a first exemplary embodiment, the fuel use encodedposition data is used to calculate the correct fuel tax for the vehicle,based on an analysis of where the vehicle was located during fuel use.Commercial trucks are often used both on and off road. Diesel fuel forhighway use is taxed at a much higher rate than diesel fuel fornon-highway use. In this embodiment, the fuel use encoded position datais used to calculate how much diesel fuel is consumed when the vehicleis not on the highway (i.e., when the lower tax rate applies). Simpleaverage MPG estimates are error prone, as off road fuel consumption isoften higher that highway fuel consumption (road condition is poorer,and off road vehicle use frequently includes using engine power to domechanical work other than driving road wheels). It should also berecognized that the fuel use encoded position data can also be used todetermine how much fuel is used on public roadways (where the fuel usetax is higher), and to determine the off road fuel use by subtractingthe fuel used on public roadways from the total fuel use to determinethe off road fuel use.

In a second exemplary embodiment, the fuel use encoded position data isused to determine how much fuel is used consumed during idle time (suchas when a vehicle is parked and the engine is not shut off). Fleetoperators want to reduce idle time, as idle time wastes fuel andincreases costs. Fuel use during idle time can be calculated in a numberof ways. Certain geographical positions (fleet yards, truck stops,loading and unloading points) can be designated for review, such thatfuel use from the fuel use encoded position data is extracted for thedesignated geographical positions, and used to determine how much fuelis consumed at those locations. Alternatively, the fuel use encodedposition data can be analyzed to determine how much fuel is consumedwhen the vehicle is on but its position remains the same (this lattertechnique is over-inclusive, as it may include fuel use required topower equipment needed while the vehicle is stationary, as well as fueluse while the vehicle is stopped for traffic and shutting down thevehicle is not practical). The over inclusiveness of the lattertechnique can be managed by eliminating geographical positions wherefuel was used to power equipment, or geographical positions where fuelwas used while sitting in traffic.

In a third exemplary embodiment, the fuel use encoded position data isused to evaluate (or to monitor) changes in fuel use patterns for avehicle regularly traveling the same route. Changes in such fuel usepatterns can be indicative of mechanical problems, such that when suchchanges are identified, it may be prudent to schedule maintenance forthe vehicle. Assume a vehicle travels from point A to point Bconsistently. By monitoring fuel use for that trip over a period oftime, a decrease in fuel efficiency may indicate a mechanical problem(dirty injectors, fouled spark plugs, etc). Of course, such fuel usechanges may be attributable to other conditions, such as changes intraffic patterns (heavy traffic encountered during one trip willincrease fuel use) or changes in vehicle loading (a trip with a heavyload will likely consume more fuel than a trip for a light load).Historical traffic data and loading data can be used to more clearlytarget fuel use pattern changes likely to be correlated to mechanicalcondition.

In general, analysis of the fuel use encoded position data will becarried out by a remote computing device. The remote computing device inat least one embodiment comprises a computing system controlled oraccessed by the fleet operator. The remote computing device can beoperating in a networked environment, and in some cases, may be operatedby a third party under contract with the fleet operator to perform suchservices. FIG. 2 schematically illustrates an exemplary computing system250 suitable for use in implementing the method of FIG. 1 (i.e., forexecuting block 18 of FIG. 1). Exemplary computing system 250 includes aprocessing unit 254 that is functionally coupled to an input device 252and to an output device 262, e.g., a display (which can be used tooutput a result to a user, although such a result can also be stored).Processing unit 254 comprises, for example, a central processing unit(CPU) 258 that executes machine instructions for carrying out ananalysis of fuel use encoded position data collected in connection withoperation of the vehicle to determine at least one operatingcharacteristic of the vehicle. The machine instructions implementfunctions generally consistent with those described above with respectto block 16 of FIG. 1, as well as those described below in blocks 30-38,with respect to FIG. 6. CPUs suitable for this purpose are available,for example, from Intel Corporation, AMD Corporation, MotorolaCorporation, and other sources, as will be well known to those ofordinary skill in this art.

Also included in processing unit 254 are a random access memory (RAM)256 and non-volatile memory 260, which can include read only memory(ROM) and may include some form of memory storage, such as a hard drive,optical disk (and drive), etc. These memory devices are bi-directionallycoupled to CPU 258. Such storage devices are well-known in the art.Machine instructions and data are temporarily loaded into RAM 256 fromnon-volatile memory 260. Also stored in the non-volatile memory are anoperating system software and ancillary software. While not separatelyshown, it will be understood that a generally conventional power supplywill be included to provide electrical power at voltage and currentlevels appropriate to energize computing system 250.

Input device 252 can be any device or mechanism that facilitates userinput into the operating environment, including, but not limited to, oneor more of a mouse or other pointing device, a keyboard, a microphone, amodem, or other input device. In general, the input device will be usedto initially configure computing system 250, to achieve the desiredprocessing (i.e., to compare subsequently collected actual route datawith optimal route data, to identify any deviations and/or efficiencyimprovements). Configuration of computing system 250 to achieve thedesired processing includes the steps of loading appropriate processingsoftware into non-volatile memory 260, and launching the processingapplication (e.g., loading the processing software into RAM 256 forexecution by the CPU) so that the processing application is ready foruse. Output device 262 generally includes any device that producesoutput information, but will most typically comprise a monitor orcomputer display designed for human visual perception of output. Use ofa conventional computer keyboard for input device 252 and a computerdisplay for output device 262 should be considered as exemplary, ratherthan as limiting on the scope of this system. Data link 264 isconfigured to enable data collected in connection with operation of avehicle to be input into computing system 250 for subsequent analysis.Those of ordinary skill in the art will readily recognize that manytypes of data links can be implemented, including, but not limited to,universal serial bus (USB) ports, parallel ports, serial ports, inputsconfigured to couple with portable memory storage devices, FireWireports, infrared data ports, wireless data communication such as Wi-Fiand Bluetooth™, network connections via Ethernet ports, and otherconnections that employ the Internet.

It should be understood that the term remote computer and the termremote computing device are intended to encompass networked computers,including servers and clients, in private networks or as part of theInternet. The fuel use encoded data can be stored by one element in sucha network, retrieved for review by another element in the network, andanalyzed by yet another element in the network. In at least oneembodiment, a vendor is responsible for storing the data, and clients ofthe vendor are able to access and manipulate the data. Whileimplementation of the method noted above has been discussed in terms ofexecution of machine instructions by a processor (i.e., the computingdevice implementing machine instructions to implement the specificfunctions noted above), the method could also be implemented using acustom circuit (such as an application specific integrated circuit).

FIG. 3 is a functional block diagram of an exemplary geographicalposition sensing system employed to implement some of the conceptsdisclosed herein. A position sensing system 60 includes a GPS component64 (which, in this embodiment, includes a transmitter, although itshould be recognized that a GPS unit without a transmitter can becoupled with a transmitter or other data link to achieve similarfunctionality). Position sensing system 60 optionally includes a dataport 68 coupled to the vehicle's odometer (or to the vehicle's on-boardcomputer), so that odometer data can be collected and combined with thefuel use encoded position data. Position sensing system 60 includes adata port 66 coupled to the vehicle's fuel injectors (any fuel injectorthat includes a fuel use sensor; noting that data port 66 can also becoupled to the vehicle's on-board computer, such that the sensor datafrom the fuel injectors is first directed to the on-board computer, andthen to position sensing system 60). GPS component 64 includes aprocessor that combines GPS data, fuel use data from the fuel injectorsensor(s), and if desired, odometer data, to generate fuel use encodedposition data that is time indexed (i.e., such that for a given point intime, one can determine the vehicle's position, the vehicle's fuel use,and optionally the vehicle's odometer reading). In a related embodiment,position sensing system 60 includes a processor separate and distinctfrom any processor in the GPS unit, such that the separate processorperforms the function of combining the GPS data, the fuel use data, andoptionally the odometer data. Such a processor can be implemented by ageneral purpose processor implementing specific machine instructions toexecute the intended function, or custom hardware circuit configured toexecute the intended function. While odometer data, fuel use data, andposition data each could be collected at a different frequencies (i.e.,at different times), and combined together to generate the fuel useencoded position data, in an exemplary and preferred embodiment, theodometer data, fuel use data, and position data are collected at thesame time, so the time indexing of each data type matches. By collectingthe different data types at the same time, one can ensure that theamount fuel use attributed to off road use is as accurate as possible.Note both the fuel use data and the odometer data normally collected bythe vehicle are accumulated numerical values, and to record a specificdata point one reads those accumulated values and combines them with thetime and position data. The purpose of collecting the odometer data isto facilitate calculation of off road fuel use. As noted above, theconcepts disclosed herein also encompass embodiments in which theodometer data is not included in the fuel use encoded position data.

If desired, position sensing system 60 can include an ID data input 62that is used to uniquely identify the vehicle, so that the fuel useencoded position data can be uniquely correlated to a specific vehicle(fleet operators will want to be able to uniquely identify fuel useencoded position data from different fleet vehicles). In one embodiment,ID data input 62 comprises a keyboard or function keys logically coupledto GPS component 64 (or to the separate processor noted above, ifimplemented). It should be recognized, however, that other data inputstructures (i.e., structures other than keyboards) can instead beimplemented, and that the concepts disclosed herein are not limited toany specific identification data input device. It should also berecognized that GPS component 64 can be configured to include in the GPSdata (or in the fuel use encoded position data) a data component thatcan be used to uniquely correlate fuel use encoded position data with aspecific vehicle, such that ID data input 62 is not required. Theinclusion of ID data input 62 facilitates the addition of other types ofdata (such as inspection data) in the fuel use encoded position data.

FIG. 4 is a functional block diagram of an exemplary system that can beemployed to implement the method steps of FIG. 1. The components includea sensor component 40, a transmitter 42, which may also have acorresponding receiver—not shown (or other data link), and a remotecomputing device 44 (generally as described above). Sensor component 40includes each element needed to collect the data elements included inthe fuel use encoded position data, and a processing element required tocombine the different types of sensor data together to generate timeindexed fuel use encoded position data. The sensor elements include atleast one fuel injector sensor to determine a quantity of fuel passingthrough an engine fuel injector (noting that each fuel injector in theengine can include the required sensor, or less than all fuel injectorsin the engine can include such sensors, so long as the appropriateadjustment is made to the fuel use data to account for injectors that donot include sensors, generally as discussed above). Other types of datafrom other sensors can also be included in the fuel use encoded positiondata, including but not being limited to odometer data. As discussedabove, the processor for combining the different data types into timeindexed fuel use encoded position data can be a separate component or aprocessor included in a GPS component. Further, it should be recognizedthat many GPS units are available that already incorporate atransmitter, such that separate transmitter 42 may not be required. Itshould be understood that the concepts disclosed herein can be used withother types of geographical position sensors/systems, and the use of theterm GPS is intended to be exemplary, rather than limiting. Sensorcomponent 40 and a transmitter 42 are part of a vehicle 41.

FIG. 5 is a schematic block diagram of an exemplary vehicle configuredto collect the fuel use encoded position data employed in the methodsteps of FIG. 1. A vehicle 50 includes GPS unit 54 (which in thisembodiment, includes a transmitter, although it should be recognizedthat a GPS unit without a transmitter can be coupled with a transmitteror other data link to achieve similar functionality). GPS unit 54 iscoupled to fuel injector sensors 52, so that geographical position dataand fuel injector data are combined by the GPS unit into fuel useencoded position data. As discussed above, the vehicle can include othersensors (such as an odometer) collecting data that is similarly includedin the fuel use encoded position data. Furthermore, the combining ofdifferent data types into fuel use encoded position data can beimplemented by a processor (not shown in FIG. 5, but discussed above)that is separate from the GPS unit.

Still another aspect of the concepts disclosed herein is a method forenabling a user to define specific parameters to be used to analyze suchfuel use encoded data. In an exemplary embodiment, a user can define ageographical parameter, and analyze the fuel use encoded data in termsof the user defined geographical parameter. In a particularly preferred,but not limiting exemplary embodiment, the geographical parameter is ageofence, which can be generated by displaying a map to a user, andenabling the user to define a perimeter “fence” around any portion ofthe map. FIG. 6 is a high level logic diagram showing exemplary overallmethod steps implemented in accord with the concepts disclosed herein,and summarized above, to utilize fuel encoded position data collected todetermine at least one operational characteristic of the vehicle, wherethe analysis includes enabling the user to define a geofence. It shouldbe understood that the method of FIG. 6 is implemented on a computingsystem remote from the vehicle collecting the fuel use encoded positiondata. In at least one exemplary, but not limiting embodiment, the fueluse encoded position data is stored in a networked location, andaccessed and manipulated by a user at a different location.

In a block 30, a map is displayed to a user. In a block 32, the user isenabled to define a geofence on the map (i.e., by prompting the user todefine such a geofence, or simply waiting until the user provides suchinput). In general, a geofence is defined when a user draws a perimeteraround a portion of the displayed map using some sort ofcomputer-enabled drawing tool. Many different software programs enableusers to define and select portions of a displayed map, thus detailedtechniques for defining a geofence need not be discussed herein. In ablock 34, the user is enabled to define a specific vehicle and a timeperiod to be analyzed (i.e., by prompting the user to define suchparameters, or simply waiting until the user provides such input). In ablock 36, fuel use encoded position data for the specified vehicle,location parameter (as defined by the geofence), and time parameter isretrieved. In a block 38, the user is enabled to define the operationalcharacteristic of the vehicle to be determined. As noted above,exemplary operational characteristics include, but are not limited to,determining a quantity of fuel consumed off road (and thus not subjectto road taxes) during the specified period, and monitoring fuel usagefor a vehicle traversing the same route a number of times to identifychanges in fuel usage not attributable to changes in load or traffic.

Yet another use for the fuel use encoded position data is to provide adata set to be used to analyze fuel consumption relative to elevationchange. Referring to FIG. 7, in a block 40 previously generated fuel useencoded position data for a specific vehicle is acquired. As discussedabove, such data is collected during operation of the vehicle, andgenerally stored in a database or memory accessible in a networkedenvironment (public or private). Accessing such data can, if desired,require entering a password or other type of credential to ensure thataccess to such data is restricted to authorized parties. In a block 42,the accessed data is analyzed to determine how road elevation affectsfuel consumption (i.e., fuel use). By quantifying how much fuel isconsumed traveling over a route with elevation changes, one can identifyalternate, possibly longer routes, that are more fuel efficient due tofewer elevation changes. This analysis may include comparing datacollected while traveling different routes connecting the same startingpoint and destination, where the different routes involve differentelevation changes. This analysis may also involve comparing actual datawith estimated fuel use over a hypothetical alternate route, to aid indetermining if the alternate route (for example, a route that includesfewer elevation changes) is more fuel efficient.

A related use for the fuel use encoded position data is to provide adata set to be used to analyze fuel consumption relative to roadsurface. Referring to FIG. 8, in a block 44 previously generated fueluse encoded position data for a specific vehicle is acquired. In a block46, the accessed data is analyzed to determine how road surfaceparameters affect fuel consumption. Analyzing fuel consumption relativeto the type of road surface will enable vehicle operators to learn whattype of road surfaces are associated with lower fuel consumption.Regularly traveled routes can then be analyzed to determine if analternate route over a different type of road surface could lead tolower fuel consumption. This analysis may include comparing datacollected while traveling different routes connecting the same staringpoint and destination, where the different routes involve differenttypes of road surfaces. For example, data collected while the vehicletravels a first relatively longer route over a road that has beenrepaved relatively recently can be compared with data collected whilethe vehicle travels over a second relatively shorter route over a roadthat has been not been repaved recently, to determine whether therelatively longer route is more fuel efficient due to the differences inthe road surfaces. Other differences in types of road surfaces includegrooved surfaces verses un-grooved surfaces, paved surfaces versesunpaved surfaces, and asphalt surfaces verses concrete surfaces.Specifics regarding road types (paved, unpaved, grooved, un-grooved,asphalt, concrete, etc.) can be added to the fuel use encoded positiondata to help in identifying trends that correlate surface type to fueluse.

Newly Disclosed Subject Matter

FIG. 9 is a flow chart showing exemplary method steps implemented tomodify a GPS logging paradigm based on the detection of one or morenon-position related parameters. In a block 50 a GPS logging paradigm isdefined. In general, such logging paradigms attempt to balancecollecting a useful amount of GPS data with minimizing airtimeconsumption. GPS logging paradigms can be based on time, such that GPSdata is collected at predetermined time intervals (such as once aminute, once an hour, or once a day, such intervals being exemplary andnot limiting). GPS logging paradigms can include collecting additionalGPS data upon vehicle start up (i.e., key on) and/or shut down (i.e.,key off). GPS logging paradigms can be based in part on collecting GPSdata according to predetermine time intervals, combined with collectingadditional GPS data when the vehicle changes speed or heading. Oncecollected, the GPS data is generally conveyed to a remote computingdevice using a wireless data link, such as a GSM data link or asatellite data link, noting that such data links are exemplary and notlimiting. GPS data can be stored until such a link becomes available.GPS data could also be stored at the vehicle for a period of time andlater conveyed to an external computing device using wireless or hardwired connections. Such a technique will require relatively more datastorage, and memory failures in the vehicle can result in loss of data.Many users find regularly data transfer via cellular or satellite to bemore convenient.

Referring to FIG. 9, at least one non-position based parameter (inaddition to key on/key off) is identified in a block 52 to be used tomodify the selected GPS logging paradigm. The concepts disclosed hereinspecifically encompass using one or more of the following parameters tochange the GPS logging paradigm: fuel use, brake temperature, oiltemperature, coolant temperature, throttle position, engine load, engineRPM, shift position/gear selected, cruise control status, and/oraccessory device status.

In a block 54 GPS data is acquired during vehicle operation according tothe selected GPS logging paradigm. In a decision block 56 adetermination is made as to whether one of the parameters selected inblock 52 has been detected. If not, the logic returns to block 54. Ifone of the non-position based (nor key on/key off) parameters isdetected in block 56, then the logic moves to a block 58 and parameterencoded GPS data is acquired (i.e., the parameter data and current GPSdata are logged, so that a later analysis can correlate the parameterdata to the GPS data).

FIG. 10A schematically illustrates a GPS logging paradigm based on GPSlogging at predetermined time intervals. The line between the start andend labels represents a vehicle route. Each shaded circle represents aGPS data logging event. The different GPS logging events are relativelyequally spaced, indicating the vehicle was traveling at a relativelyconstant speed during the route. This is but one possibly type of a GPSlogging paradigm that can be defined in block 50 of FIG. 9.

FIG. 10B schematically illustrates a GPS logging paradigm based on GPSlogging at predetermined time intervals, modified based on positionbased parameters. Rather than logging GPS data according to elapsedtime, the GPS data in this paradigm is logged when the vehicle changesspeed or direction. Significantly, note the relative dearth of GPSlogging in the lower portion of the route, where the vehicle is notmaking any changes in direction. Such a route can correspond to arelatively straight section of highway. Along such a route segment,where there is no change in speed or heading, there is little need tocollect GPS data, and eliminating some GPS logging events will reduce aquantity of airtime consumed.

FIG. 10C schematically illustrates the GPS logging paradigm of FIG. 10Bmodified based on detecting a non-position based parameter. In thiscase, the non-position based parameter is turning cruise control on andoff. The cruise control was turned on at a location 60, and was turnedoff at a location 62. The GPS logging paradigm was modified at locations60 and 62, and the status of the cruise control was recorded at thoselocations, as well as the GPS coordinates. When an operator of thevehicle reviews the route data, the fact that cruise control was notturned on until location 60, when the route suggests that cruise controlcould have been turned on near location 64. This type of data willenable operators to educate drivers on how to more efficiently operatevehicles (the use of cruise control generally results in fuel savings).It should be recognized that while FIG. 10C relates to modifying the GPSlogging paradigm based on cruise control status, that the conceptsdisclosed herein specifically encompass modifying the GPS loggingparadigm based parameters such as fuel use, brake temperature, oiltemperature, coolant temperature, throttle position, engine load, engineRPM, shift position/gear selected, and/or accessory device status. Theterm accessory device encompasses devices that increase parasitic loadand are likely to reduce fuel economy, such as manual cooling fans, airconditioning units, etc.

FIG. 11 is a screen shot of a web page upon which a vehicle owner canview fuel use data overlaid upon vehicle route data, where the fuel usedata was collected using the method of FIG. 9. In addition to loggingGPS data according to a predefined GPS logging paradigm based, GPS datawas also collected when fuel use increased or decreased. The combinationof fuel use data and GPS data, presented to a user in the format shownin FIG. 11, enables vehicle operators (such as fleet managers) toquickly review vehicle routes to determine areas associated withrelatively good and relatively poor fuel economy. That enables vehicleoperators to analyze their routes, to identify conditions associatedwith greater or lesser fuel efficiency, which may lead to redesigningroutes that are traversed on a reoccurring basis to maximize fuelefficiency.

The route for a commercial diesel truck shown in FIG. 11 includessegments where fuel economy was over 7.0 MPG (generally segment 80 shownin green), segments where fuel economy was between 5.1 and 6.9 MPG(generally segment 82 shown in yellow), and segments where fuel economywas under 5.0 MPG (generally segment 84, shown in red, noting the colorsare exemplary and not limiting). Specifically, segment 80 a, segment 80b segment 80 c, and segment 80 d represent portions of the routeassociated with good fuel economy. Segment 82 a, segment 82 b segment 82c, and segment 82 d represent portions of the route associated withmoderate fuel economy. Segment 84 a, segment 84 b segment 84 c, andsegment 84 d represent portions of the route associated with poor fueleconomy. Note segment 84 c is the relatively largest poor fuel economysegment, and the vehicle operator may focus his attention on thatportion of the route first, to see if some rerouting might enable thatarea to be bypassed. Further, such a report can also be analyzed fromthe aspect of the time of day. For example, familiarity with this routemight suggest that poor economy in segment 84 c is due to trafficvolumes, and changing the timing of the route may result in increasingthe fuel efficiency of that portion of the route, assuming that suchtime shifting is practical.

Exemplary GPS Device with Onboard Computing Environment

FIG. 12 is a functional block diagram of an exemplary telematics deviceadded to an enrolled vehicle to implement one or more of the methods ofFIGS. 1 and 9.

An exemplary telematics unit 160 includes a controller 162, a wirelessdata link component 164, a memory 166 in which data and machineinstructions used by controller 162 are stored (again, it will beunderstood that a hardware rather than software-based controller can beimplemented, if desired), a position sensing component 170 (such as aGPS receiver), and a data input component 168 configured to extractvehicle data from the vehicle's data bus and/or the vehicle's onboardcontroller (noting that the single input is exemplary, and not limiting,as additional inputs can be added, and such inputs can be bi-directionalto support data output as well).

The capabilities of telematics unit 160 are particularly useful to fleetoperators. Telematics unit 160 is configured to collect position datafrom the vehicle (to enable vehicle owners to track the current locationof their vehicles, and where they have been) and to collect vehicleoperational data (including but not limited to engine temperature,coolant temperature, engine speed, vehicle speed, brake use, idle time,and fault codes), and to use data link 164 to (wirelessly in anexemplary but not limiting embodiment) convey such data to vehicleowners. These data transmission can occur at regular intervals, inresponse to a request for data, or in real-time, or be initiated basedon parameters related to the vehicle's speed and/or change in location,and/or the change in logging parameters discussed above. The term“real-time” as used herein is not intended to imply the data aretransmitted instantaneously, since the data may instead be collectedover a relatively short period of time (e.g., over a period of secondsor minutes), and transmitted to the remote computing device on anongoing or intermittent basis, as opposed to storing the data at thevehicle for an extended period of time (hour or days), and transmittingan extended data set to the remote computing device after the data sethas been collected. Data collected by telematics unit 160 can beconveyed to the vehicle owner using data link 164. If desired,additional memory can be included to temporarily store data when thedata link cannot transfer data. In particularly preferred embodimentsthe data link is GSM or cellular technology based.

In at least one embodiment, the controller is configured to implementthe method of FIG. 1 by using one or more of data collected fromposition sensing component 170 (in some embodiments, a GPS receiver) anddata from data input component 168. In a related embodiment, thecontroller is configured to implement the method of FIG. 9 by using oneor more of data collected from position sensing component 170 and datafrom data input component 168.

Non-Transitory Memory Medium

Many of the concepts disclosed herein are implemented using a processorthat executes a sequence of logical steps using machine instructionsstored on a physical or non-transitory memory medium. It should beunderstood that where the specification and claims of this documentrefer to a memory medium, that reference is intended to be directed to anon-transitory memory medium. Such sequences can also be implemented byphysical logical electrical circuits specifically configured toimplement those logical steps (such circuits encompass applicationspecific integrated circuits).

Although the concepts disclosed herein have been described in connectionwith the preferred form of practicing them and modifications thereto,those of ordinary skill in the art will understand that many othermodifications can be made thereto within the scope of the claims thatfollow. Accordingly, it is not intended that the scope of these conceptsin any way be limited by the above description, but instead bedetermined entirely by reference to the claims that follow.

The invention in which an exclusive right is claimed is defined by thefollowing:
 1. A method for generating non-position parameter encodedposition data from a vehicle equipped with a geographical positionsystem, the method comprising the steps of: (a) collecting geographicalposition data from the vehicle during vehicle operation according to adefined logging paradigm, the geographical position data being timeindexed; (b) determining if a predefined parameter is present duringvehicle operation, the predetermined parameter comprising a parameterother than time, speed, direction, and distance; (c) in response todetecting the predefined parameter during vehicle operation, modifyingthe defined logging paradigm to collect additional geographical positiondata at the time the predefined parameter is detected, and (d)collecting data corresponding to the predefined parameter detected. 2.The method of claim 1, further comprising the steps of combining theparameter data and the geographical position data together at thevehicle to produce parameter encoded position data.
 3. The method ofclaim 2, further comprising the step of conveying the parameter encodedposition data to a remote computing device that is physically spacedapart from the vehicle.
 4. The method of claim 1, wherein the predefinedparameter comprises at least one of the following: (a) an increase in anamount of fuel consumed by the vehicle; (b) a decrease in an amount offuel consumed by the vehicle; (c) a change in a status of a cruisecontrol component; (d) a change in a status of an accessory componentassociated with a parasitic load; and (e) a change in throttle position.5. The method of claim 1, wherein the predefined parameter comprises atleast one of the following: (a) any change in engine RPM; (b) a changein engine RPM over a predetermined magnitude; (c) any change in engineload (d) a change in engine load over a predetermined magnitude; (e) anychange in oil temperature; (f) a change in oil temperature over apredetermined magnitude; (g) any change in coolant temperature; and (h)a change in coolant temperature over a predetermined magnitude.
 6. Themethod of claim 1, wherein the predefined parameter comprises at leastone of the following: (a) any change in brake temperature; and (b) achange in brake temperature over a predetermined magnitude.
 7. Ageographical position system for use in a vehicle, the geographicalposition system comprising: (a) a positioning sensing component forcollecting geographical position data from the vehicle during vehicleoperation, the geographical position data being time indexed; (b) afirst data port for receiving non-position related parameter data fromthe vehicle during operation of the vehicle, the non-position relatedparameter data being time indexed to correlate the non-position relatedparameter data to a specific point in time, the non-position relatedparameter comprising at least one of fuel use, engine RPM, engine load,temperature, cruise control status, and accessory device status; (c) aprocessor for implementing the functions of: (i) triggering the loggingof geographical position data according to a predefined paradigm; and(ii) triggering the logging of non-position related parameter data andposition and geographical position data based on the detection of anevent associated the non-position related parameter data; and (d) a datalink for conveying the non-position related parameter data and thegeographical position data to a remote computing device.
 8. The systemof claim 7, wherein the data link comprises a wireless data link.
 9. Thesystem of claim 7, wherein the processor is configured to combine theparameter data and the geographical position data together at thevehicle to produce parameter encoded position data.
 10. A method forgenerating and using event encoded position data from a vehicle equippedwith a geographical position system to determine at least one eventbased operational characteristic of the vehicle, the method comprisingthe steps of: (a) collecting geographical position data from the vehicleduring vehicle operation; (b) collecting non-position related parameterdata from the vehicle during operation of the vehicle based on thedetection of a predefined event, the non-position related parameter databeing time indexed to correlate the non-position related parameter datato a specific point in time, the non-position related parametercomprising at least one of fuel use, engine RPM, engine load,temperature, cruise control status, and accessory device status; (c)conveying the geographical position data and the non-position relatedparameter a remote computing device, such data collectively comprisingevent encoded position data; and (d) analyzing the event encodedposition data to determine at least one operating characteristic of thevehicle.
 11. The method of claim 10, wherein the step of analyzing theevent encoded position data to determine at least one operatingcharacteristic of the vehicle comprises the step of displaying a routetraversed by a vehicle with fuel use overlaid on the route, the fuel usebeing determined by fuel use included in the event encoded positiondata.
 12. The method of claim 10, wherein the step of analyzing theevent encoded position data to determine at least one operatingcharacteristic of the vehicle comprises the step of displaying a routetraversed by a vehicle with cruise control use overlaid on the route,the cruise control use being determined by cruise control statusincluded in the event encoded position data.
 13. The method of claim 10,wherein the step of analyzing the event encoded position data todetermine at least one operating characteristic of the vehicle comprisesthe step of displaying a route traversed by a vehicle with engine RPMdata overlaid on the route, the engine RMP data having been included inthe event encoded position data.
 14. The method of claim 10, wherein thestep of analyzing the event encoded position data to determine at leastone operating characteristic of the vehicle comprises the step ofdisplaying a route traversed by a vehicle with engine load data overlaidon the route, the engine load data having been included in the eventencoded position data.
 15. The method of claim 10, wherein the step ofanalyzing the event encoded position data to determine at least oneoperating characteristic of the vehicle comprises the step of displayinga route traversed by a vehicle with accessory device use overlaid on theroute, the accessory device use being determined by accessory devicestatus included in the event encoded position data.
 16. The method ofclaim 10, wherein the step of analyzing the event encoded position datato determine at least one operating characteristic of the vehiclecomprises the step of displaying a route traversed by a vehicle withthrottle position data overlaid on the route, the throttle position datahaving been included in the event encoded position data.
 17. The methodof claim 10, wherein the step of analyzing the event encoded positiondata to determine at least one operating characteristic of the vehiclecomprises the step of displaying a route traversed by a vehicle withvehicle temperature data overlaid on the route, the temperature datahaving been included in the event encoded position data.
 18. The methodof claim 10, wherein the step of analyzing the event encoded positiondata to determine at least one operating characteristic of the vehiclecomprises the step of displaying a route traversed by a vehicle withtransmission gear selection position data overlaid on the route, thetransmission gear selection data having been included in the eventencoded position data.
 19. The method of claim 10, wherein the step ofanalyzing the event encoded position data to determine at least oneoperating characteristic of the vehicle comprises the step of enabling auser to define a geofence, such that only event encoded position datafalling within the confines of the geofence are included within theanalysis.
 20. A method for generating non-position parameter encodedposition data from a vehicle equipped with a geographical positionsystem, the method comprising the steps of: (a) collecting geographicalposition data from the vehicle during vehicle operation according to adefined logging paradigm, the geographical position data being timeindexed; (b) determining if a predefined parameter is present duringvehicle operation, wherein the predefined parameter comprises at leastone of the following: (i) an increase in an amount of fuel consumed bythe vehicle; (ii) a decrease in an amount of fuel consumed by thevehicle; (iii) a change in a status of a cruise control component; (iv)a change in a status of an accessory component associated with aparasitic load; and (v) a change in throttle position (c) in response todetecting the predefined parameter during vehicle operation, modifyingthe defined logging paradigm to collect additional geographical positiondata at the time the predefined parameter is detected, and (d)collecting data corresponding to the predefined parameter detected. 21.A non-transitory memory medium having machine instructions storedthereon for carrying out the steps of claim
 20. 22. A method forgenerating non-position parameter encoded position data from a vehicleequipped with a geographical position system, the method comprising thesteps of: (a) collecting geographical position data from the vehicleduring vehicle operation according to a defined logging paradigm, thegeographical position data being time indexed; (b) determining if apredefined parameter is present during vehicle operation, wherein thepredefined parameter comprises at least one of the following: (i) anychange in engine RPM; (ii) a change in engine RPM over a predeterminedmagnitude; (iii) any change in engine load; (iv) a change in engine loadover a predetermined magnitude; (v) any change in oil temperature; (vi)a change in oil temperature over a predetermined magnitude; (vii) anychange in coolant temperature; and (viii) a change in coolanttemperature over a predetermined magnitude; (c) in response to detectingthe predefined parameter during vehicle operation, modifying the definedlogging paradigm to collect additional geographical position data at thetime the predefined parameter is detected, and (d) collecting datacorresponding to the predefined parameter detected.
 23. A non-transitorymemory medium having machine instructions stored thereon for carryingout the steps of claim
 22. 24. A non-transitory memory medium havingmachine instructions stored thereon for carrying out the steps ofclaim
 1. 25. The non-transitory memory medium of claim 24, which furtherincludes machine instructions stored thereon for carrying out the stepsof claim
 4. 26. The non-transitory memory medium of claim 24, whichfurther includes machine instructions stored thereon for carrying outthe steps of claim
 5. 27. The non-transitory memory medium of claim 24,which further includes machine instructions stored thereon for carryingout the steps of claim
 6. 28. A method for generating non-positionparameter encoded position data from a vehicle equipped with ageographical position system, the method comprising the steps of: (a)collecting geographical position data from the vehicle during vehicleoperation according to a defined logging paradigm, the geographicalposition data being time indexed; (b) determining if a predefinedparameter is present during vehicle operation, wherein the predefinedparameter comprises at least one of the following: (i) any change inbrake temperature; and (ii) a change in brake temperature over apredetermined magnitude; (c) in response to detecting the predefinedparameter during vehicle operation, modifying the defined loggingparadigm to collect additional geographical position data at the timethe predefined parameter is detected, and (d) collecting datacorresponding to the predefined parameter detected.
 29. A non-transitorymemory medium having machine instructions stored thereon for carryingout the steps of claim 28.